%
% Hello! Here's how this works:
%
% You edit the source code here on the left, and the preview on the
% right shows you the result within a few seconds.
%
% Bookmark this page and share the URL with your co-authors. They can
% edit at the same time!
%
% You can upload figures, bibliographies, custom classes and
% styles using the files menu.
%
% If you're new to LaTeX, the wikibook at
% http://en.wikibooks.org/wiki/LaTeX
% is a great place to start, and there are some examples in this
% document, too.
%
% Enjoy!
%
\documentclass[11pt]{article}

\usepackage{listings}
\usepackage[english]{babel}
\usepackage[utf8x]{inputenc}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{authblk}
\usepackage{todonotes}

\title{A Distributed System for an LEGO NXT Robot}
%\author{Adria Lopez, Jonathan Sharyari, Luis Mauricio,\\ Niklas Forsmark, Othman chraibi, Torbjörn Elebjörk}'

\renewcommand\Authands{ and }

\lstset{% parameters for all code listings
	language=Python,
	frame=single,
	basicstyle=\small,  % nothing smaller than \footnotesize, please
	tabsize=2,
	numbers=left,
%	framexleftmargin=2em,  % extend frame to include line numbers
	%xrightmargin=2em,  % extra space to fit 79 characters
	breaklines=true,
	breakatwhitespace=true,
	prebreak={/},
	captionpos=b,
	columns=fullflexible,
	escapeinside={\#*}{\^^M}
}



\begin{document}
\author[1]{Adria Lopez \thanks{A.A@university.edu}}
\author[1]{Othman Chraibi\thanks{B.B@university.edu}}
\author[2]{Jonathan Sharyari\thanks{josh015@student.uu.se}}
\author[2]{Luis Mauricio\thanks{luma1619@student.uu.se}}
\author[2]{Niklas Forsmark\thanks{nifo1013@student.uu.se}}
\author[2]{Torbj\"{o}rn Elebj\"{o}rk\thanks{toel2273@student.uu.se}}
\affil[1]{Department of Mechanical Engineering, Tongji University}
\affil[2]{Department of Computer Science, Uppsala University}
\maketitle

\begin{abstract}
Your abstract.
\end{abstract}

\section{Introduction}

\subsection{Description of the LEGO Mindstorms NXT}
The Mindstorms NXT is a robotics kit, developed by LEGO. It is supplied with a set of links and joints of plastic, allowing for various robot designs. The standard kit is supplied with three motors that can be used to steer revolute joints directly, or prismatic joints by designing it using the available links. 

The central part of the robot is the \emph{intelligence brick} which controls the motors, receives input from the sensors, send information via bluetooth and can be programmed to do any number of things based on these things. The operating system originally supplied with the kit is the NXT-G, but there are a large variety of 3rd part operating systems that can be installed on the intelligence brick. The OS that was chosen to flash the brick with is leJOS, a 3rd party Java platform available on the NXT due to its well documented features and the simplicity of once again working Java. ADA was considered to be used, another object-oriented language that is tailored for use on embedded systems like the NXT, but it was ultimately decided to go with leJOS.

In order to interact with the environment, the kit is supplied with a small set of sensors in addition to the motors; Two touch sensor, a light sensor, a sound sensor and an ultrasonic sensor. These can be connected to the intelligence brick for information processing, and the intelligence brick can in turn communicate with an external device by sending data over bluetooth.\cite{legousermanual}


\section{The Robot}


\subsection{Physical design}
The robot is built very simple. Using the Mindstorms Education pamhplet that was included in the box, the robot was constructed in standard form. Onto this base form the ultrasonic sensor was added on the frame above the brick mounted upon the last motor. The reasoning behind this is to get a clear 360 degree field of vision for the sensor and simplifying the process of scanning an area. With this design only the sensor has to rotate thus eliminating the need to rotate and subsequently recalibrating the direction the robot is facing after a sucessful scan.

How did we build it in a physical sense, and what were the motives behind our choices? Which sensors did we use, and why/why not? What are the disadvantages with this design (dead angles, drift etc..)


\section{Server}
The server has two main responsibilities. The first is to communicate with the robot, forwarding instructions and processing data received from the robot. The second is to communicate with client, receiving requests regarding the robot, see figure \ref{projectoverview}. Communication between the server and the robot is done through bluetooth communication. Messages between server and robot are sent as strings of text, whereas messages between the client and the server are sent over the network as java-objects, as explained in \ref{secapi}.

\begin{figure}
\includegraphics[width=\textwidth]{LegoProjectOverview.pdf}
\caption{An overview of how information is passed between the client and the server, including the most important internal threads and objects.}
\label{projectoverview}
\end{figure}


\subsection{classes}
The server has four major classes; ClientListener, RobotListener, ThreadCommunication and Map. The classes ClientListener and RobotListener are run as two separate threads, whereas Map is a shared object of all classes. This object can be manipulated through the class ThreadCommunication.

\subsubsection*{ClientListener}
ClientListener is the interface towards clients. It listens for an incoming stream of java-objects of the type \texttt{ClientMessage} from a client. The communication is one-to-many, in the sense that any request from the client can result in several replies from the server.  To this extent, this class has two sub-threads for receiving and sending data. Replies are sent as a stream of messages of the type \texttt{ServerMessage} to the client. The reply messages contain map-specific information - each message describes a position in the map, and a description of that position. A position can be free, unknown, contain an obstacle or contain the robot.

The sent and received messages are fetched from and forwarded to the ThreadCommunication class, which stores and manipulates the data.

\subsubsection{RobotListener}
The class RobotListener works similar to ClientListener, and is used to communicate with the robot over a Bluetooth Connection. The communication is one-to-one, and always initiated by the server. Thus, the server must always receive a reply before a new request can be made. The nature of the requests and replies is covered in the section below. 

The sent and received messages are fetched from and forwarded to the ThreadCommunication class, which stores and manipulates the data.

\subsubsection*{ThreadCommunication}
This class is used to forward and store messages between the client and the robot, and vice versa. Client messages are translated from java objects into corresponding XML-strings that can be forwarded to the robot. The replies from the robot are first analysed in order to correctly update the internal map, and new \texttt{ServerMessage}s are generated from this map to be sent to the client.

\subsubsection*{Map}
The map class describes an internal map. The map is a simple two-dimensional array, corresponding to the environment. The robot ultrasonic sensor replies in numbers of centimetres, whereas the map is scaled as 1:2. This means that one position in both x- and y-axis corresponds to two centimetres in the room, or expressed differently, each position in the array corresponds to a $4 cm^2$ space in the room. The map used the replies from the robot, to update the map. Depending on the nature of the replies, different measures are taken.

When the reply describes robot movement, an internal representation of the robot is updated to reflect the new position and orientation. Messages are then generated to update the map accordingly - the position of the robot is updated, whereas the previous position is considered to be free and also all the positions passed in order to reach the new position.

When the reply describes a response from the ultrasonic sensor, it will be processed if an object is found within an interval that can be considered trustworthy, during this project, this distance has been 0.75 to 1m. The map is then updated to reflect the new obstacle, and all position between the robot and the obstacle are considered to be free. Messages are then generated to reflect this. Considering that one message is generated for each position in the map, this can be up to fifty messages.

\section{Client}
In this project, a client was implemented to steer the robot. This is a simplistic client, using the java swing-libraries. The client initiates a connection to the server, and sends requests on demand of the user. The request can be to move forward, turn or scan the area - these requests can be sent together, but only one of each kind in each message. The client may also request the robot to automatically search the area.

The client maintains a map, identical to that in the server but with fewer methods of manipulation. Messages from the server contain a position, and a description of what that position contains - the client then draws this information on the screen. The map array is drawn with each pixel corresponding to a position in the array, and the color of the pixel the content of that position. The colors are blue (free), black (unknown), red(robot) and yellow(obstacle). Due to uncertainties in the robot positioning and the responses of the ultrasonic sensor, positions in the map are frequently overwritten, and it is always the last received information that is reflected on the map.

\section{Communications: Client-Server-Robot}
\label{secapi}
\subsection{API Between Robots and Server}
To make the server independent of the robot, and to allow connecting multiple robots from multiple groups, a common robot-server API was discussed between the project groups. This API consists of a common XML-formatting. The benefits are that it allows for the usage of built-in XML parsers, which are not dependent on the actual formatting of the XML-string, as long as it follows the standard.

This approach allows for a common communication language between robots and servers, to some extent. If a robot has additional functionality, the messages have a specific type of field to send this additional information.

\subsubsection*{Message: Server to robot}
\begin{lstlisting}
<s2r>
	<move req='''' />
	<rotate req=''''/>
	<scan req=''''/>
	<reboot/>
	<GXField attr=''''>
</s2r>
\end{lstlisting}

\subsubsection*{Message: Robot to Server}
\begin{lstlisting}
<r2s>
	<move req='''' real=''''/>
	<rotate req='''' real=''''/>
	<scan n='''' n1='''' n2='''' ..../>
	<reboot/>
	<GXField attr=''''>
</r2s>
\end{lstlisting}

\begin{itemize}
\item
\texttt{move} has the attribute \emph{req} and when sent as a reply from the robot, the attribute \emph{real}. \emph{req} is the distance the robot is requested to move forward, in centimetres (negative number thus implies moving backwards). The robot replies with the same value on the attribute \emph{req} as it received as a request. The \emph{real} field is used if the robot for some reason was unable to carry a request out. If this occurs, the field will contain the actual distance moved. If the robot was able to carry the request out, the attributes \emph{real} and \emph{req} will contain the same value.

\item
\texttt{rotate} works similar to \texttt{move} described above. The values are interpreted as the number of degrees to turn, counter-clockwise. Naturally, a negative number corresponds to rotating clockwise.

\item
\texttt{scan} is used to request that the robot scans the room with an ultra-sound sensor. The server sends the request with an attribute \emph{req}. This number describes the number of scans to be performed. If this number is four, the robot will scan in $0^\circ$, $90^\circ$, $180^\circ$ and $270^\circ$. The robot then replies with the attributes \emph{n, n1, n2...} where \emph{n} is the number of scans performed, and \emph{n1...n4} are the values of the performed scan. Each value is the distance in centimetres to the nearest object in that angle, or the constant 255 if no obstacle was seen within one meter.

\item
\texttt{reboot} is sent if the server requests the robot to reboot. The robot replies with this message when it is ready, just before it performs the reboot.

\item
\texttt{GXField} is the format of additional fields to be sent. Any group that needs to send fields outside the common API must name the fields with GX as a prefix, where X is the identifier of the group. Examples of such messages are the fields \texttt{G4Drive} and \texttt{G4Turn}. The four indicates that the group identifier is four, and turn and drive are used to control the robot in a different manner that in the API.

\end{itemize}

\subsection{API Between Server and Client}
The server can communicate with a client over the network, providing the client is able to pass messages in the form of java objects. The server and the client share a common set of classes, most importantly the classes \texttt{ServerMessage} and \texttt{ClientMessage} shown in picture \ref{messageobjects}. The client and the server open a network connection through a socket. The client sends a request to the server, by sending a \texttt{ClientMessage} to the server, whereas the server will eventually reply by sending one or more \texttt{ServerMessage} objects back to the client.

A \texttt{ClientMessage}-request can be for the robot to turn a specified angle, or move a specified distance. If so, the client will send a message with the \texttt{drive} and \texttt{turn} fields set to that amount. An alternative is that the client requests the robot to start or stop turning/moving. This can be used to steer the robot with a keyboard - the robot will move as long as you hold down the button. Additionally, the \texttt{ClientMessage}-request has the field \texttt{terminate} to request the link between the server and robot to go down, \texttt{date} to indicate when this request was send. The field \texttt{Additional} is used for development purposes, so as to avoid unnecessary changes to the API.

A \texttt{ServerMessage}-reply from the server will always contain a map-position and a value for that position. This requires that the client and the server have the same implementation of the map - a fixed-size \todo{What size is it then?} two-dimentional array. The value of the position can indicate either that the position is \emph{free} \todo{value?}, contains an \emph{obstacle} \todo{value?}, contains the \emph{robot} \todo{value?} or that it is \emph{unknown} (\texttt{null}). The ServerMessage also contains a timestamp message, showing the time of creation of the message.

\begin{figure}
\includegraphics{Messages.pdf}
\caption{The two main classes in the common server/client API.}
\label{messageobjects}
\end{figure}

\section{Discussion}
Why did we decide for java on the client? On the server? (javadoc on the server, erlang was the alternative we were considering)
Why did we decide for Ada on the robot? What pros and cons does it have?


\section{Proposed Further Work}
During this project, the fundamental parts of a distributed robot have been laid and it can easily be extended to add several additional features. The most important such feature would be to implement some form of localisation, in order to better keep track on the robot and more truthfully represent the work environment. As manually steering the robot for mapping purposes is tedious work, automated mapping algorithms could be implemented. A simplistic algorithm is already implemented, as explained above, but could be greatly improved.
C
\bibliographystyle{plain} 
\bibliography{lego}

\end{document}